Update export for new planes to make boilerplates work - #1699
Merged
Conversation
This comment has been minimized.
This comment has been minimized.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fix tenant export (both SQL and GraphQL flows) to include the routing binding plane and the catalog plane, so a redeployed tenant DB can resolve its own subdomains (login was 404-ing).
Why
resolve_route() (routing 6.1.0) reads hostname_bindings/route_bindings/catalog_private.apis. The export produced none of them:
bindings: tables carry no database_id column (ownership flows via domain_id → routing_public.domains), so neither the flat {databaseId} filter nor WHERE database_id = $1 can scope them — the tables weren't exported at all
catalog_private.apis: dot-qualified keys are skipped in the GraphQL flow (bare-name collisions in the meta build), and the catalog_sync trigger doesn't fire during replica-mode migration replay — so the rows must be derived at export time (this also covers sources whose catalog table is empty because they were themselves built from a replay)
Changes
pgpm/export: manifest keys + updated_at exclusions for hostname_bindings/route_bindings; new TableConfig.filterViaDomainIds; SQL flow scopes bindings via a routing_public.domains subquery, GraphQL flow via a one-time domain-id pre-fetch + in:` filter support inGraphQLClient> -pgpm/export: newcatalog-projection.tsderivescatalog_private.apisfrom the exportedapisrows (mirrorscatalog_private.tg_apis_catalog_sync1:1); run by both flows so their output stays byte-identical
pgpm/export: drop the catalog_private.functions manifest key — unaddressable via the meta API in a mixed build, and this also removes the last SQL/GraphQL output divergence (plus its now-dead columnDefaults entry)
Tests
E2E export-flow snapshot updated: second-workspace deploy now includes migrate/catalog_private.apis.sql